Contextual guidelines are typically developed to improve usability and ensure consistency of locations, products, and services. For example, the Americans with Disabilities Act (ADA) was enacted in part to improve access to commercial buildings for people with disabilities through a set of consistent regulations that affect building codes. The ADA also includes a Section 508 directed to accessibility of electronic and information technology. Sub-part 1194.22 a-p of Section 508 addresses accessibility of Web content. A portion of this sub-part is also addressed by the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG), which are intended to improve access to information in Web pages through a set of consistent guidelines for creating the Web pages. For example, the guidelines suggest providing a text alternative to an audio element of a Web page whenever possible, so that deaf people can read the content of the audio element. In general, the WCAG provides a set of guidelines that describe principles of accessible design. Each guideline includes a number of checkpoints that explain how the guideline applies in typical content development scenarios. The checkpoints are sufficiently specific so that someone reviewing a Web page or Web site may verify that each checkpoint has been satisfied.
The guidelines and checkpoints of the WCAG are comprehensible by humans who design Web pages and who review the Web pages for conformance to the guidelines and checkpoints. However, it would be desirable to enable automatic review of Web pages for conformance, and to enable automatic design corrections when nonconformances are identified. Unfortunately, the guidelines and checkpoints include some assertions that are abstract, and not well suited to traditional automation techniques. For example, one of the checkpoints includes a requirement that a developer “use the clearest and simplest language appropriate for a site's content.” With traditional automation techniques, it is difficult to determine whether the “clearest” and “simplest” language that is “appropriate” for a site has been used.
There are a number of programming methodologies to ensure that a source document satisfies formatting, structural, and other constraints. In general, a program can evaluate grammar in the source document to detect one or more patterns. When a predetermined pattern is detected, a corresponding predetermined action is taken in relation to the pattern. Often this pattern detection is implemented using software written in a standard programming language, such as C. A programming language is versatile for writing customized program code that can detect the predefined patterns and accomplish the predefined actions. Program code can also report detection of a pattern (or lack of a pattern), so that a human can intervene in cases of vague guidelines. However, it is difficult to update and maintain program code. Also, customized program code is often difficult to reuse for evaluating and correcting a wide variety of source documents.
Another approach in evaluating a source document for compliance to the guidelines and checkpoints is to define a schema. A schema defines a framework to which a source document must conform. Thus, a schema can be used to validate the structure, order, and values of elements and attributes in source documents. However, schemas require that the structure of the entire document be defined. Also, schemas must validate against the grammar of the source document, not against a contextual guideline. Further, there are no implicit mechanisms for simply reporting violations of vague guidelines that may require some human intervention.
A modified schema approach, called SCHEMATRON, was developed by Academia Sinica Computing Centre of the Republic of China (Taiwan), and is based on tree patterns in a source document rather than the grammar of the source document. SCHEMATRON is a structure validation language that utilizes an eXtensible Markup Language (XML) open schema to confirm whether a source eXtensible Hypertext Markup Language (XHTML) document conforms to the schema. In general, SCHEMATRON provides a few unique elements that simplify the use of XPath expressions. As an example, online documentation for SCHEMATRON (at the following web page on the world wide web: ascc.net/xml/resource/schematron/WAI-example) illustrates a sample schema that confirms whether a source XHTML document conforms to the W3C WCAG. The schema includes “rule” expressions for matching an XPath context attribute in a source XHTML document. Upon a match, the schema provides “assert” expressions that contain error statements indicating each specific nonconformance with the accessibility guidelines.
However, careful evaluation reveals that SCHEMATRON uses an inefficient process to accomplish its task. Specifically, SCHEMATRON first requires an eXtensible Stylesheet Language (XSL) document to transform the schema into an intermediate XSL document. The intermediate XSL document is then applied to the source XHTML document to execute XPath expressions that evaluate the source XHTML document and produce the error statements. In addition to being complex, SCHEMATRON does not provide any means to mechanically repair nonconforming source XHTML documents. Repairs must be implemented by manually editing the nonconforming source XHTML document based on the error statements. Further, SCHEMATRON is limited to processing XHTML source documents. It would therefore be desirable to provide a more efficient technique for evaluating any source document for conformance to a set of contextual guidelines. It is further desirable to provide summary and detailed reports that are organized by categories for a user to analyze and correct problems manually if desired. However, the technique should also enable mechanical or automated correction of any nonconforming portion of the source document that is identified.